ขอบเขตของปัญหา สิ่งที่ควรตระหนักก็คือ ความท้าทายของปัญหาปี ค.ศ. 2000 ไม่ได้เกิดกับเมนเฟรมที่ใช้โคบอลเป็นส่วนใหญ่เท่านั้น แต่ปัญหานี้มีโอกาสเกิดขึ้นได้ กับภาษาโปรแกรมทุกภาษา และระบบคอมพิวเตอร์ทุกชนิด เพียงแต่โอกาสที่จะเกิดกับแอพพลิเคชัน ที่เขียนขึ้นจากโคบอลที่รันบนเมนเฟรมมีมากกว่าภาษาอื่นๆ เท่านั้น ขอบเขตปัญหาจะกระจายไปทั่ววงการเทคโนโลยีสารสนเทศ เนื่องจากการแทนปีด้วยเลขสองตำแหน่ง มีอยู่ทั่วไป ระบบฐานข้อมูล (Database) เกือบทุกระบบ จะใช้รูปแบบนี้กัน รวมทั้งโปรแกรมและแอพพลิเคชันส่วนใหญ่ก็เช่นกัน วันที่จะแฝงอยู่ทั่วไปในไมโครโค้ด คิวรี โพรซีเดอร์ ดาต้า และสกรีนวันที่ จะอยู่ในซิสเต็มซอฟต์แวร์ด้วย และแน่นอน ในบางกรณี องค์กรจำเป็นต้องแทนที่ระบบปฏิบัติการคอมไพเลอร์ ยูทิลิตี้ ด้วยเวอร์ชันใหม่ ที่รองรับต่อปี 2000 แล้ว เพราะข้อมูลมีการใช้งานร่วมกัน ระหว่างยูสเซอร์หรือข้ามเน็ตเวิร์กกัน บางครั้งข้อมูลนั้น ก็มีการใช้งานทั้งภายในองค์กร และส่งออกไปให้องค์กรอื่นๆ ด้วย ดังนั้น ปัญหาจะส่งผลกระทบต่อธุรกิจทุกชนิด เอเจนซี สถาบัน หรือคนที่ใช้คอมพิวเตอร์ หลายคนก็อาจสงสัยว่า ถ้าเช่นนั้น ทำไมไม่ใช้รูปแบบการเก็บวันที่เป็น 4 ตำแหน่งเสีย และก็แก้ปัญหานี้ตั้งแต่ต้นคำตอบสำหรับเรื่องนี้ ส่วนหนึ่งก็คือ ความต้องการประหยัดพื้นที่การจัดเก็บดังกล่าวข้างต้น และอีกเหตุผลหนึ่งก็คือ ไม่มีใครคาดว่า ระบบที่สร้างขึ้นตั้งแต่เมื่อหลายสิบปีก่อน จะมีอายุการใช้งานที่ยืนยาว และใช้มาได้เรื่อยๆ จนถึงปัจจุบัน อาจจะเรียกได้ว่าเป็นความโชคดี (ที่แฝงโชคร้าย) โดยบังเอิญขององค์กรก็ได้ ที่ระบบใช้งานได้นานเกินคาด สรุปได้ว่า สาเหตุหลักของปัญหามีอยู่ด้วยกันเป็น 2 ส่วนคือ
เมื่อระบบใช้งานมาเป็นเวลานาน แน่นอนว่า ข้อมูลที่จัดเก็บไว็ก็ยิ่งพอกพูน สะสมเพิ่มมากขึ้นทุกที จนบังต้นตอของปัญหามิด บางครั้งผู้ที่พัฒนาระบบในยุคแรกๆ ก็ไม่อยู่แล้ว ย้ายบริษัทบ้าง บางรายก็มีตำแหน่งสูงขึ้น หรือบางรายก็หันไปทำอย่างอื่นแล้ว ระบบที่จัดทำในช่วงแรกๆ บางครั้งก็ไม่มีการจัดทำเอกสารประกอบที่ดีไว้ (ส่วนใหญ่จะเป็นเช่นนี้) ผู้ที่เข้ามาสานต่อ ก็เพียงพัฒนาระบบต่อยอดขึ้นไปอีก โดยไม่เห็นว่ารากฐานของระบบเดิม เริ่มคลอนแคลน และไม่มั่นคง พร้อมที่จะล้มลงมาได้ทุกขณะแล้ว
|
